Mobile terminals are an important part in the whole mobile operating and serving system. With the more and more complex terminal functions, the probability that problems occur in software of the terminals increases prominently. As the competition between operators will become fiercer and fiercer in the future, how to effectively assure users' experience, improve users' loyalty, and keep efficient quality of service and low-cost device maintenance has become an important concern for the operators and terminal vendors.
An event trigger mechanism has been defined in an existing Open Mobile Alliance Device Management (OMA DM) specification, which is mainly used in the case that when a Device Management (DM) service delivers a diagnosing or fault reporting task and then a terminal makes a diagnosis or a fault occurs, the terminal sends a diagnostic result or fault reports collected by the terminal back to the server. This event trigger mechanism is limited to the reporting of diagnostic result or fault reports from the terminal to the server, but the terminal does not carry out any other operations.
In an existing solution, an approach of Trap Management Object (Trap MO) is provided for diagnosis and fault tracking and reporting running on the terminal. This Trap MO provides two kinds of trigger mechanisms, i.e. time-based trigger mechanism and event-based trigger mechanism. When a device management server delivers a diagnosing or fault tracking operation, the operation is delivered in a form of a Trap MO and the Trap MO contains parameters related to the diagnosing or fault reporting. After collecting the diagnostic data or fault reports, a DM agent reports the collected diagnostic data or fault reports to the DM server upon the occurrence of a trigger condition. FIG. 1 shows a specific processing procedure.
In process 1, the DM server delivers a diagnosing or fault tracking operation in a form of a Trap MO.
In process 2, the DM agent in a terminal device collects diagnostic data or fault reports.
In process 3, the trigger condition occurs, and the DM agent executes a triggered operation.
In process 4, the DM agent sends the diagnostic data or fault tracking reports to the DM server.
The format of a Trap MO provided in the existing OMA DM protocol is shown in FIG. 2.
In this figure, TrapID is a unique identifier identifying the Trap MO.
The leaf node CM indicates data collection policies for the Trap MO.
The leaf node Result stores diagnostic data or fault reports to be reported to the DM server.
The leaf node ServerID identifies the DM server to which the DM agent will send diagnostic data or fault tracking reports
The leaf node Enable acts as a switch of a Trap for controlling whether to enable the Trap.
Reporting/Type is adapted to indicate whether the Trap MO is time (TM)-triggered or event (EV)-triggered.
The value of the leaf node Reporting/Value is adapted to, if the Trap MO is time-triggered, indicate the interval at which the collected diagnostic data or fault reports are sent to the server, or if the Trap MO is event-triggered, indicate how many times the event occurs when the diagnostic data or fault reports are sent to the server.
TrapRef corresponds to other Trap MOs that may be referenced by this Trap MO, and a TrapRef is used here to refer to the referenced Trap MO.
Although the existing OMA DM trigger mechanism provides the two different mechanisms, time-based trigger mechanism and event-based trigger mechanism, it has drawbacks as follows.
1. The function performed by the terminal is limited to the reporting to the server when the trigger condition is satisfied, resulting in great limitation in application.
2. It is impossible to recover from the failure or make a backup automatically when an abnormal condition such as a failure or a fault occurs on the terminal.